Today's hardware developer has a limited suite of tools for developing, debugging, and testing firmware code or pre-boot applications (e.g., hardware drivers). In contrast, an operating system (“OS”) application developer has a wide range of powerful development tools at his or her disposal, which enable recursive compiling and source level debugging within the OS environment. Examples of such tool suites include Microsoft's Visual C and Visual .NET.
In a typical personal computer (“PC”) architecture, the pre-boot runtime is an initialization and configuration phase of the PC that occurs prior to the OS runtime phase. Firmware code is responsible for initializing the PC up to a point that the OS loaded off of media, such as a hard disk, can take over. The firmware code can include applications stored in a boot firmware device mounted on a motherboard, option read only memories (“ROMs”) of add-in cards, and the like. Since a large portion of firmware code only runs during the pre-boot runtime, debugging and testing this firmware code can be awkward and cumbersome. Often, debugging and testing can require repeated booting of the PC to find and remedy a single coding error. Rebooting may be necessary to reinitialize the firmware environment, reinitialize the firmware code under test, and/or reinitialize the hardware device under test after a runtime error.
One tool available to the hardware developer is an in circuit emulator (“ICE”), such as those available from American Arium Corporation of Tustin, Calif. An ICE is a physical device that is coupled between a central processing unit (“CPU”) and the CPU socket, and enables the hardware developer to monitor pin traffic on the CPU. The hardware developer can insert halt instructions into the firmware code under test to freeze the CPU operation at significant processing points and analyze the logic states of the CPU pins.
However, an ICE is physically intrusive into the PC. The ICE does not eliminate the need to constantly reboot the PC to generate the pre-boot environment necessary to execute and test a pre-boot application or firmware code. Furthermore, due to the lack of an OS environment to support powerful development tools, hardware developers are often relegated to coding the firmware code in assembly language. Coding in assembly language limits the hardware developer's access to powerful source level tool suites.